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The "font" Top-Level Media Type 

Abstract 
This memo serves to register and document the "font" top-level media 
type, under which subtypes for representation formats for fonts may 
be registered. This document also serves as a registration 
application for a set of intended subtypes, which are representative 
of some existing subtypes already in use, and currently registered 
under the "application" tree by their separate registrations. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8081. 


Copyright Notice 


Copyright (c) 2017 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


The process of setting type in computer systems and other forms of 
text presentation systems uses fonts in order to provide visual 
representations of the glyphs. Just as with images, for example, 
there are a number of ways to represent the visual information of the 
glyphs. Early font formats often used bitmaps, as these could have 
been carefully tuned for maximum readability at a given size on low- 
resolution displays. More recently, scalable vector outline fonts 
have come into widespread use. In these fonts, the outlines of the 
glyphs are described, and the presentation system renders the outline 
in the desired position and size. 


Over time, a number of standard formats for recording font 
descriptions have evolved. Internet Media Types [RFC6838] are used 
to label content carried over Internet protocols. This document 
defines a new top-level type "font" according to Section 4.2.7 of 
[RFC6838]. This top-level type indicates that the content specifies 
font data. Under this top-level type, different representation 
formats of fonts may be registered. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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2. Background and Justification 


Historically, there has not been a registration of formats for fonts. 
More recently, there have been several representation formats 
registered as media subtypes under the "application" top-level type 
(for example, "“application/font-woff"). However, with the rapid 
adoption of web fonts (based on the data from HTTP Archive 
[HTTP-Archive-Trends] showing a huge increase in web font usage from 
1% in the end of 2010 to 50% across all sites in the beginning of 
2015), custom fonts on the web have become a core web resource. As 
the in-depth analysis [Font-Media-Type-Analysis] shows, the lack of 
the intuitive top-level font type is causing significant confusion 
among developers -- while currently defined font subtypes are 
severely under-utilized, there are many more sites that already use 
nonexistent (but highly intuitive) media types such as "font/woff", 
"font/ttf", and "font/truetype". At the same time, the majority of 
sites resort to using generic types such as "application/octet- 
stream", "text/plain", and "text/html", or use unregisterable types 
such as "application/x-font-ttf". 


Contrary to the expectations of the W3C WebFonts WG, which developed 
Web Open Font Format (WOFF), the officially defined media types such 
as “application/font-woff" and "application/font-sfnt" see a very 
limited use -- their adoption rates trail far behind as the actual 
use of web fonts continues to increase. The members of the W3C 
WebFonts WG concluded that the use of the "application" top-level 
type is not ideal. First, the "application" sub-tree is treated 
(correctly) with great caution with respect to viruses and other 
active code. Secondly, the lack of a top-level type means that there 
is no opportunity to have a common set of optional parameters, such 
as are specified here. Third, fonts have a unique set of licensing 
and usage restrictions, which makes it worthwhile to identify this 
general category with a unique top-level type. 


The W3C WebFonts WG decided [WG-tlt] that the situation can be 
significantly improved if a set of font media types is registered 
using "font" as a dedicated top-level type. Based on the data 
analysis presented above, we conclude that it is the presence of 
simple and highly intuitive media types for images that caused their 
widespread adoption, where the correct usage of existing media types 
reaches over 97% for all subtypes in the "image" tree. The WG 
considers that, keeping in mind a rapid adoption of fonts on the web, 
the registration of the top-level media type for fonts along with the 
intuitive set of subtypes that reflect popular and widely used data 
formats would further stimulate the adoption of web fonts, 
significantly simplify web server configuration process, and 
facilitate the proper use of media types for fonts. 
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3. Security Considerations 


Fonts are interpreted data structures that represent collections of 
different tables containing data that represent different types of 
information, including glyph outlines in various formats, hinting 
instructions, metrics and layout information for multiple languages 
and writing systems, rules for glyph substitution and positioning, 
etc. In particular, the hinting instructions for TrueType glyphs 
represent executable code that has the potential to be maliciously 
constructed (for example, intended to hang the interpreter). There 
are many existing, already standardized font table tags and formats 
that allow an unspecified number of entries containing predefined 
data fields for storage of variable-length binary data. Many 
existing font formats (TrueType [truetype-wiki], OpenType and OFF 
[opentype-wiki], SIL Graphite, WOFF, etc.) are based on the table- 
based SFNT (scalable font) format, which is extremely flexible, 
highly extensible, and offers an opportunity to introduce additional 
table structures when needed, in an upward-compatible way that would 
not affect existing font rendering engines and text layout 
implementations. However, this very extensibility may present 
specific security concerns -- the flexibility and ease of adding new 
data structures makes it easy for any arbitrary data to be hidden 
inside a font file. There is a significant risk that the flexibility 
of font data structures may be exploited to hide malicious binary 
content disguised as a font data component. 


Fonts may contain ’hints’, which are programmatic instructions that 
are executed by the font engine for the alignment of graphical 
elements of glyph outlines with the target display pixel grid. 
Depending on the font technology utilized in the creation of a font, 
these hints may represent active code interpreted and executed by the 
font rasterizer. Even though hints operate within the confines of 
the glyph outline conversion system and have no access outside the 
font rendering engine, hint instructions can be quite complex, anda 
maliciously designed complex font could cause undue resource 
consumption (e€.g., memory or CPU cycles) on a machine interpreting 
it. Indeed, fonts are sufficiently complex that most (if not all) 
interpreters cannot be completely protected from malicious fonts 
without undue performance penalties. 


Widespread use of fonts as necessary components of visual content 
presentation warrants that careful attention should be given to 
security considerations whenever a font is either embedded into an 
electronic document or transmitted alongside media content as a 
linked resource. While many existing font formats provide certain 
levels of protection of data integrity (such mechanisms include, 
e.g., checksums and digital signatures), font data formats provide 
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neither privacy nor confidentiality protection internally; if needed, 
such protection should be provided externally. 


IANA Considerations 


This specification registers a new top-level type, "font", in the 
standards tree, adds it as an alternative value of "Type Name" in the 
media types registration form [Media-Type-Registration], and 
registers several subtypes for it. 


Definition and Encoding 


The "font" as the primary media content type indicates that the 
content identified by it requires a certain graphic subsystem such as 
a font rendering engine (and, in some cases, a text layout anda 
shaping engine) to process it as font data, which in turn may require 
a certain level of hardware capabilities such as certain levels of 
CPU performance and available memory. The "font" media type does not 
provide any specific information about the underlying data format and 
how the font information should be interpreted -- the subtypes 
defined within a "font" tree name the specific font formats. 
Unrecognized subtypes of "font" should be treated as "application/ 
octet-stream". Implementations may pass unrecognized subtypes to a 
common font-handling system, if such a system is available. 


Fragment Identifiers for Font Collections 


Fragment identifiers for font collections identify one font in the 
collection by the PostScript name (name ID=6) [ISO.14496-22.2015]. 
This is a string, no longer than 63 characters and restricted to the 
printable ASCII subset, codes 33 ? 126, except for the 10 characters 
a ae TPE; CCE, oar GIE ryt ELE; Sry EI y ror which are forbidden 
by [ISO.14496-22.2015]. 


In addition, the following 6 characters could occur in the PostScript 
name but are forbidden in fragments by [RFC3986], and thus must be 
escaped: E rer, ENE Og TSL rija: 


If (following un-escaping) this string matches one of the PostScript 
names in the name table, that font is selected. For example, "#Foo- 
Bold" refers to the font with PostScript name "Foo-Bold" and 
"#Caret%5Estick" refers to the font with PostScript name 
"Caret*stick". If the name does not match, or if a fragment is not 
specified, the first font in the collection is matched. Note that 
the order of fonts in collections may change as the font is revised, 
so relying on a particular font in a collection always being first is 
unwise. 
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4.3. Registration Procedure 


New font formats should be registered using the online form 
[Media-Type-Registration]. [RFC6838] should be consulted on 
registration procedures. In particular, the font specification 
should preferably be freely available. If the font format can 
contain multiple fonts, a fragment identifier syntax should also be 
defined. 


Note that new parameter sub-values may be defined in the future. If 
an implementation does not recognize a sub-value in the comma- 
separated list, it should ignore the sub-value and continue 
processing the other sub-values in the list. 


4.4. Subtype Registrations 


In this section, the initial entries under the top-level ’font’ media 
type are specified. They also serve as examples for future 
registrations. 


For each subtype, an @font-face format identifier is listed. This is 
for use with the @font-face src descriptor, defined by the Cascading 
Style Sheets Level 3 (CSS3) Fonts specification 
[W3C.CR-css-—fonts-—3-20131003]. That specification is normative; the 
identifiers here are informative. 


4.4.1. Generic SFNT Font Type 
Type name: font 
Subtype name: sfnt 
Required parameters: None 
Optional parameters: 
1) Name: outlines 


Values: a comma-separated subset of True Type Font (TTF), 
Compact Font Format (CFF), and SVG 


This parameter can be used to specify the type of outlines 
provided by the font. The value "TTF" shall be used when a 
font resource contains glyph outlines in TrueType format, the 
value "CFF" shall be used to identify fonts containing 
PostScript/CFF outlines [cff-wiki], and the value SVG 
[svg-wiki] shall be used to identify fonts that include SVG 
outlines. TTF, CFF, or SVG outlines can be present in various 
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combinations in the same font file; therefore, this optional 
parameter is a list containing one or more items, separated by 
commas. Order in the list is not significant. 


2) Name: layout 


Values: a comma-separated subset of OTL, Apple Advanced 
Typography (AAT), and SIL 


This parameter identifies the type of implemented support for 
advanced text layout features. The predefined values "OTL", 
"AAT", and "SIL", respectively, indicate support for OpenType 
text layout, Apple Advanced Typography, or Graphite SIL. More 
than one shaping and layout mechanism may be provided by the 
same font file; therefore, this optional parameter is a list 
containing one or more items, separated by commas. Order in 
the list is not significant. 


Encoding considerations: Binary 


Interoperability considerations: As it was noted in the first 
paragraph of the Security Considerations section, a single font 
file can contain encoding of the same glyphs using several 
different representations, e.g., both TrueType and PostScript 
(CFF) outlines. Existing font rendering engines may not be able 
to process some of the particular outline formats, and downloading 
a font resource that contains only an unsupported glyph data 
format would be futile. Therefore, it is useful to clearly 
identify the format of the glyph outline data within a font using 
an optional parameter, and allow applications to make decisions 
about downloading a particular font resource sooner. Similarly, 
another optional parameter identifies the type of text shaping and 
layout mechanism that is provided by a font. 


Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) 
specification [1S0.14496-22.2015] being developed by ISO/IEC SC29/ 
WG11. 


Applications that use this media type: All applications that are 
able to create, edit, or display textual media content. 


Note that "font/sfnt" is an abstract type from which the (widely 
used in practice) "font/ttf" and "font/otf" types are conceptually 
derived. Use of "font/sfnt" is likely to be rare in practice, and 
might be confined to: 


Uncommon combinations such as "font/sfnt; layout=sil" that do 
not have a shorter type 
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Cases where a new parameter value is registered 


Test cases, experimentation, etc. 
Additional information: 
Magic number(s): The TrueType fonts and OFF / OpenType fonts 
containing TrueType outlines should use 0x00010000 as the 


'sfnt’ version number. 


The OFF / OpenType fonts containing CFF data should use the tag 
‘OTTO’ as the ’sfnt’ version number. 


File extension(s): Font file extensions used for OFF / OpenType 
fonts: .ttf and .otf 


Typically, the .ttf extension is only used for fonts containing 
TrueType outlines, whereas the .otf extension can be used for 
any OpenType/OFF font, and either can be used with the TrueType 
or CFF outlines. 

Macintosh file type code(s): (no code specified) 

Macintosh Universal Type Identifier code: "public.font" 

@font-face Format: None 


Fragment Identifiers: None 


Deprecated Alias: The existing registration "application/font- 
sfnt" is deprecated in favor of "font/sfnt". 


Person & email address to contact for further information: 
Vladimir Levantovsky (vladimir.levantovsky@monotype.com) . 


Intended usage: COMMON 
Restrictions on usage: None 


Author: The ISO/IEC 14496-22 "Open Font Format" specification is a 
product of the ISO/IEC JTC1 SC29/WG11. 


Change controller: The ISO/IEC has change control over this 
specification. 
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4.4.2. TTF Font Type 
Type name: font 
Subtype name: ttf 
Required parameters: None 
Optional parameters: 
Name: layout 
Values: a comma-separated subset of OTL, AAT, and SIL 


This parameter identifies the type of support mechanism for 
advanced text layout features. The predefined values "OTL", 
"AAT", and "SIL" respectively indicate support for OpenType 
text layout, Apple Advanced Typography, or Graphite SIL. More 
than one shaping and layout mechanism may be provided by the 
same font file; therefore, this optional parameter is a list 
containing one or more items, separated by commas. Order in 
the list is not significant. 


Encoding considerations: Binary 


Interoperability considerations: As it was noted in the first 
paragraph of Section 3, a single font file can contain encoding of 
the same glyphs using several different representations, e.g., 
both TrueType and PostScript (CFF) outlines. Existing font 
rendering engines may not be able to process some of the 
particular outline formats, and downloading a font resource that 
contains only an unsupported glyph data format would be futile. 
Therefore, it is useful to clearly identify the format of the 
glyph outline data within a font using an optional parameter, and 
allow applications to make decisions about downloading a 
particular font resource sooner. Similarly, another optional 
parameter identifies the type of text shaping and layout mechanism 
that is provided by a font. 


Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) 
specification [1S0.14496-22.2015] being developed by ISO/IEC SC29/ 
WG11. 


Applications that use this media type: All applications that are 
able to create, edit, or display textual media content. 


Lilley Standards Track [Page 9] 


RFC 8081 The ’font’ Top-Level Type February 2017 


Additional information: 


Magic number(s): The TrueType fonts and OFF / OpenType fonts 
containing TrueType outlines should use 0x00010000 as the 
'sfnt’ version number. 


File extension(s): Font file extensions used for TrueType / OFF / 
OpenType fonts: .ttf and .otf 


Typically, the .ttf extension is only used for fonts containing 
TrueType outlines, while the .otf extension may be used for any 
OpenType/OFF font, either with TrueType or CFF outlines. 


Macintosh file type code(s): (no code specified) 
Macintosh Universal Type Identifier code: "public.truetype-font" 
@font-face Format: truetype 


Fragment Identifiers: None 


Person & email address to contact for further information: 
Vladimir Levantovsky (vladimir.levantovsky@monotype.com) . 


Intended usage: COMMON 
Restrictions on usage: None 


Author: The ISO/IEC 14496-22 "Open Font Format" specification is a 
product of the ISO/IEC JTC1 SC29/WG11. 


Change controller: The ISO/IEC has change control over this 
specification. 


4.4.3. OpenType Layout (OTF) Font Type 
Type name: font 
Subtype name: otf 
Required parameters: None 
Optional parameters 


Name: outlines 
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Values: a comma-separated subset of TIF, CFF, and SVG 


This parameter can be used to specify the type of outlines 
provided by the font. The value "TTF" shall be used when a 
font resource contains glyph outlines in TrueType format, the 
value "CFF" shall be used to identify fonts containing 
PostScript/CFF outlines, and the value SVG shall be used to 
identify fonts that include SVG outlines. TIF, CFF, or SVG 
outlines can be present in various combinations in the same 
font file; therefore, this optional parameter is a list 
containing one or more items, separated by commas. Order in 
the list is not significant. 


oding considerations: Binary 


eroperability considerations: As it was noted in the first 
paragraph of the Security Considerations section, a single font 
file can contain encoding of the same glyphs using several 
different representations, e.g., both TrueType and PostScript 

(CFF) outlines. Existing font rendering engines may not be able 
to process some of the particular outline formats, and downloading 
a font resource that contains only unsupported glyph data format 
would be futile. Therefore, it is useful to clearly identify the 
format of the glyph outline data within a font using an optional 
parameter, and allow applications to make decisions about 
downloading a particular font resource sooner. Similarly, another 
optional parameter identifies the type of text shaping and layout 
mechanism that is provided by a font. 


lished specification: ISO/IEC 14496-22 "Open Font Format" (OFF) 
specification [1S0.14496-22.2015] being developed by ISO/IEC SC29/ 
WG11. 


lications that use this media type: All applications that are 
able to create, edit, or display textual media content. 


itional information: 


Magic number(s): The TrueType fonts and OFF / OpenType fonts 
containing TrueType outlines should use 0x00010000 as the 
'sfnt’ version number. 


The OFF / OpenType fonts containing CFF outlines should use the 
tag ‘OTTO’ as the ’sfnt’ version number. There is no magic 
number for SVG outlines; these are always accompanied by either 
TrueType or CFF outlines, and thus use the corresponding magic 
number. 
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File extension(s): Font file extensions used for OFF / OpenType 
fonts: .ttf and .otf 
Typically, the .ttf extension is only used for fonts containing 
TrueType outlines, while the .otf extension can be used for any 
OpenType/OFF font, either with TrueType, CFF, or SVG outlines. 


Macintosh file type code(s): (no code specified) 


Macintosh Universal Type Identifier code: "public.opentype-font" 


@font-face Format: opentype 


Fragment Identifiers: None 


Person & email address to contact for further information: 
Vladimir Levantovsky (vladimir.levantovsky@monotype.com) . 


Intended usage: COMMON 
Restrictions on usage: None 


Author: The ISO/IEC 14496-22 "Open Font Format" specification is a 
product of the ISO/IEC JTC1 SC29/WG11. 


Change controller: The ISO/IEC has change control over this 
specification. 


4.4.4. Collection Font Type 
Type name: font 
Subtype name: collection 
Required parameters: None 
Optional parameters 
Name: outlines 
Values: a comma-separated subset of TIF, CFF, and SVG 
This parameter can be used to specify the type of outlines 
provided by the font. The value "TTF" shall be used when a 
font resource contains glyph outlines in TrueType format, the 
value "CFF" shall be used to identify fonts containing 


PostScript/CFF outlines, and the value SVG shall be used to 
identify fonts that include SVG outlines. TTF, CFF, or SVG 
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outlines can be present in various combinations in the same 
font file; therefore, this optional parameter is a list 
containing one or more items, separated by commas. Order in 
the list is not significant. 


Encoding considerations: Binary 


Interoperability considerations: As it was noted in the first 
paragraph of the Security Considerations section, a single font 
file can contain encoding of the same glyphs using several 
different representations, e.g., both TrueType and PostScript 
(CFF) outlines. Existing font rendering engines may not be able 
to process some of the particular outline formats, and downloading 
a font resource that contains only unsupported glyph data format 
would be futile. Therefore, it is useful to clearly identify the 
format of the glyph outline data within a font using an optional 
parameter, and allow applications to make decisions about 
downloading a particular font resource sooner. Similarly, another 
optional parameter identifies the type of text shaping and layout 
mechanism that is provided by a font. 


Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) 
specification [1S0.14496-22.2015] being developed by ISO/IEC SC29/ 
WG11. 


Applications that use this media type: All applications that are 
able to create, edit, or display textual media content. 


Additional information: 


Magic number(s): The TrueType fonts and OFF / OpenType fonts 
containing TrueType outlines should use 0x00010000 as the 
'sfnt’ version number. 


The OFF / OpenType fonts containing CFF outlines should use the 
tag ‘OTTO’ as the ’sfnt’ version number. There is no magic 
number for SVG outlines; these are always accompanied by either 
TrueType or CFF outlines, and thus use the corresponding magic 
number. 


File extension(s): Font file extensions used for OFF / TrueType 
and OpenType fonts: .ttc 


Macintosh file type code(s): (no code specified) 


Macintosh Universal Type Identifier code: "public.truetype- 
collection-font" 
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@font-face Format: collection 


Fragment Identifiers: See Section 4.2. 


Person & email address to contact for further information: 
Vladimir Levantovsky (vladimir.levantovsky@monotype.com) . 


Intended usage: COMMON 
Restrictions on usage: None 


Author: The ISO/IEC 14496-22 "Open Font Format" specification is a 
product of the ISO/IEC JTC1 SC29/WG11. 


Change controller: The ISO/IEC has change control over this 
specification. 


4.4.5. WOFF 1.0 
Type name: font 
Subtype name: woff 
Required parameters: None 
Optional parameters: None 
Encoding considerations: Binary 
Interoperability considerations: None 


Published specification: This media type registration updates the 
WOFF specification [W3C.REC-WOFF-20121213] at W3C. 


Applications that use this media type: WOFF is used by web browsers, 
often in conjunction with HTML and CSS. 


Additional information: 


Magic number(s): The signature field in the WOFF header MUST 
contain the "magic number" 0x774F4646 (’WwOFF’ ) 

File extension(s): woff 

Macintosh file type code(s): (no code specified) 

Macintosh Universal Type Identifier code: "org.w3.woff" 
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@font-face Format: woff 


Fragment Identifiers: None 


Deprecated Alias: The existing registration "application/font- 
woff" is deprecated in favor of "font/woff". 


Person & email address to contact for further information: 
Chris Lilley (www-font@w3.org). 


Intended usage: COMMON 
Restrictions on usage: None 


Author: The WOFF specification is a work product of the World Wide 
Web Consortium’s WebFonts working group. 


Change controller: The W3C has change control over this 
specification. 


4.4.6. WOFF 2.0 
Type name: font 
Subtype name: woff2 
Required parameters: None 
Optional parameters: None 
Encoding considerations: Binary 
Interoperability considerations: WOFF 2.0 is an improvement on WOFF 
1.0. The two formats have different Internet Media Types and 


different @font-face formats, and they may be used in parallel. 


Published specification: This media type registration is extracted 
from the WOFF 2.0 specification [W3C.CR-WOFF2-20150414] at W3C. 


Applications that use this media type: WOFF 2.0 is used by web 
browsers, often in conjunction with HTML and CSS. 


Additional information: 


Magic number(s): The signature field in the WOFF header MUST 
contain the "magic number" 0x774F4632 (’wOF2’) 


File extension(s): woff2 
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Macintosh file type code(s): (no code specified) 


Macintosh Universal Type Identifier code: "org.w3.woff2" 
@font-face Format: woff2 
Fragment Identifiers: See Section 4.2. 


Person & email address to contact for further information: 
Chris Lilley (www-font@w3.org). 


Intended usage: COMMON 
Restrictions on usage: None 


Author: The WOFF2 specification is a work product of the World Wide 
Web Consortium’s WebFonts working group. 


Change controller: The W3C has change control over this 


specification. 
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